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ABSTRACT 


Although  the  approach  to  systems  development  varies  widely,  the  overall  approach  to  human 
factors  engineering  in  military  system  development  is  usually  specified  by  US  MIL-STD-46855. 
The  approach  set  out  in  MIL-STD-46855  emphasizes  analysis  and  reflects  the  traditional 
waterfall  model  of  systems  development,  although  there  is  nothing  inherent  in  the  standard  to 
prevent  an  iterative  approach.  A  review  of  ten  Canadian  Forces  development  projects  concluded 
that  the  application  of  human  factors  engineering,  was  enhanced  by  the  use  of  a  Human 
Engineering  Project  Plan  based  on  MIL-STD-46855.  A  subsequent  survey  of  approaches  used  to 
include  user  requirements  in  development  projects  showed  large  differences  in  attitude  and 
practice.  The  survey  identified  the  need  for  aids  to  facilitate  the  inclusion  of  users’  requirements 
in  the  Statements  of  Requirements.  Designers  also  need  to  know  the  context  in  which  their 
system  or  equipment  will  be  employed.  This  is  particularly  true  of  personal  equipment.  Few 
designers  of  advanced  systems  have  knowledge  of  operational  conditions  and  constraints.  One 
development  (the  Soldier's  Day)  being  undertaken  for  the  Canadian  Forces  is  aimed  at  providing 
designers  with  the  context  of  the  roles  and  tasks  that  operators  perform,  as  an  aid  to 
understanding  how  equipment  will  be  used. 
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EXECUTIVE  SUMMARY 


In  the  Canadian  Forces  (CF),  Human  Factors  Engineering  (HFE)  is  a  recommended  rather  than  a 
required  activity.  HFE  is  often  construed  as  a  hindrance  to  overall  project  development  instead 
of  being  recognized  as  a  key  to  ensuring  a  project’s  overall  success.  HHE  issues  are  not  often 
considered  in  the  planning  process  until  late  in  development,  if  at  all,  when  a  human  factors 
related  problem  is  identified.  At  this  point,  due  to  the  constraints  of  the  project,  there  may  be 
little  scope  for  change  that  is  feasible  or  economical.  This  paper  advocates  an  earlier 
consideration  of  HFE  issues  than  is  currently  employed.  In  particular,  an  early  understanding  of 
the  users  and  their  roles  is  urged  as  a  key  feature  of  the  overall  process. 

A  review  of  ten  CF  development  projects  concluded  that  the  application  of  human  factors 
engineering  was  enhanced  by  the  use  of  a  Human  Engineering  Project  Plan  based  on  MEL-STD- 
46855.  A  subsequent  survey  of  approaches  used  to  include  user  requirements  in  development 
projects  showed  large  differences  in  attitude  and  practice.  The  survey  identified  the  need  for  aids 
to  facilitate  the  inclusion  of  users’  requirements  in  the  Statements  of  Requirements  (SORs). 

In  the  Department  of  National  Defence  (DND)  acquisition  process,  users  are  not  accessed 
directly  but  they  are  only  represented  through  the  inclusion  of  the  Requirements  Officer  (a  full¬ 
time  user  representative).  While  in  theory  this  affords  a  means  for  users  to  play  a  detailed  role  in 
equipment  development,  there  are  a  number  of  disadvantages  of  this  user  representative  strategy 
such  as  the  hostage  effect,  limited  representation  of  rank,  limited  representation  of  user  areas, 
lack  of  continuity  of  staff  and  the  potentially  biased  viewpoint  of  user  representatives. 

In  order  to  counter  the  problems  associated  with  full-time  user  representation,  it  is  necessary  to 
consider  ways  which  may  increase  user  involvement  and  improve  user  representation  in  the 
development  and  acquisition  process.  Ideally,  this  will  mark  the  beginning  of  an  evolutionary 
process  towards  a  more  user-centered  design  strategy  tailored  to  the  particular  requirements  of 
the  CF.  Two  differing  approaches  are  being  examined  at  DCIEM  to  accomplish  this  goal.  The 
first  focuses  on  allowing  part-time  user  representatives  to  develop  a  profile  of  themselves,  the 
second  centers  around  a  more  rigid  management  of  HFE  procedures. 

One  of  the  problems  with  much  of  the  development  and  acquisition  process,  is  that  it  emphasizes 
technical  areas  and  pays  little  or  no  attention  to  issues  of  context.  Designers  need  to  know  the 
context  in  which  their  system  or  equipment  will  be  employed.  This  is  particularly  true  of 
personal  equipment.  Few  designers  of  advanced  systems  have  detailed  knowledge  of  operational 
conditions  and  constraints.  One  development  (the  Soldier's  Day)  being  undertaken  for  the 
Canadian  Forces  is  aimed  at  providing  designers  with  the  context  of  the  roles  and  tasks  that 
operators  perform,  as  an  aid  to  understanding  how  equipment  will  be  used. 
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INTRODUCTION 


In  the  development  of  military  systems,  users  needs  are  addressed  through  the  application 
of  human  factors  engineering  (HFE).  In  the  Canadian  Forces  (CF),  HFE  is  a  recommended 
rather  than  a  required  activity^ .  The  Department  of  National  Defence  (DND)  guide  to  project 
management  recommends  (DND,  1988)  that  project  managers  ensure  that  the  contractor  apply 
two  US  Department  of  Defense  documents  which  govern  human  engineering:  MIL-H-46855B 
and  MIL-STD-1472D.  US  MIL-H-46855B:  Human  engineering  requirements  for  military 
systems,  equipment,  and  facilities  specifies  the  overall  approach  to  HFE  in  military  system 
development.  The  approach  set  out  in  MIL-STD-46855  emphasizes  analysis  starting  from  a 
stated  operational  requirement  and  includes  activities  related  to  design,  experiments,  tests,  and 
trials.  US  MIL-STD  1472D  Human  engineering  design  criteria  for  military  systems,  equipment, 
and  facilities  provides  human  engineering  design  standards. 

It  has  been  recognized  that  the  Department  of  National  Defence  (DND)  development  and 
acquisition  process  is  ‘cumbersome’  and  ‘time  consuming’  (Auditor  General,  1992).  The 
process  varies  from  project  to  project.  The  applicable  military  standards  are  rarely  followed  to 
the  letter  and  may  even  be  completely  overlooked  (Bee vis  &  Hill,  1983).  HFE  is  often 
considered  to  be  intuitively  obvious,  and  devoting  effort  and  funds  to  HFE  is  frequently  seen  as  a 
hindrance  to  the  overall  project  development  instead  of  being  recognized  as  a  key  to  ensuring  a 
project’s  overall  success.  HFE  issues  are  often  not  considered  in  the  planning  process  until  late 
in  development,  if  at  all,  when  a  human  factors  related  problem  is  identified.  At  this  point,  due 
to  the  constraints  of  the  project,  there  may  be  little  scope  for  change  that  is  feasible  or 
economical. 

This  paper  advocates  an  earlier  consideration  of  HFE  issues  than  is  currently  employed. 

In  particular,  an  early  understanding  of  the  users  and  their  roles  is  urged  as  a  key  feature  of  the 
overall  process. 


SURVEY  OF  DEVELOPMENT  AND  ACQUISITION  IN  THE  CF 


In  order  to  better  understand  how  to  integrate  HFE  issues  into  the  overall  acquisition 
process  for  personal  clothing  and  equipment,  a  study  was  conducted  to  determine  organizational 
attitudes  to  the  inclusion  of  user  requirements  in  DND  development  projects  (Donati,  1994).  The 
study  consisted  of  participant  observation  and  a  questionnaire  survey  of  persons  responsible  for 
representing  users  in  project  management  positions  (Director  of  Land  Requirements  (DLR), 
Director  of  Soldier  Systems  (DSSPM),  Director  Land  Armaments  and  Electronics  Engineering 
and  Maintenance  (DLAEEM)),  or  for  applying  HFE.  The  results  of  the  questionnaire  survey 
showed  large  differences  in  the  attitude  to,  and  application  of,  human  factors  issues  (Donati, 
1994) .  As  a  result,  there  is  often  poor  integration  of  HFE,  as  a  whole,  into  the  development  and 
acquisition  documentation;  poor  consultation  with  stakeholders;  and  negligible  involvement  of 


Hn  contrast,  US  DoD  instruction  5000.2  Part  6,  Section  H,  requires  that  "design  requirements  shall  be  established  to 
develop  effective  man-machine  interfaces  and  preclude  systems  characteristics  which:  require  complex  cognitive, 
physical,  or  sensory  skills;  require  complex  manpower  or  training  intensive  tasks;  or  result  in  frequent  or  critical 
errors. ...  Manpower,  personnel,  training,  health  hazard,  and  safety  concerns  will  be  translated  into  man-machine 
interface  design  issues  to  be  addressed  during  systems  engineering." 


actual  users  in  the  development  and  acquisition  process^. 


To  gain  a  better  understanding  of  personal  equipment  development  and  acquisition,  data 
from  the  study  were  analyzed  using  Hierarchical  Task  Analysis  (HTA).  HTA  is  a  process  of 
“gathering  relevant  information  about  human  requirements  for  operating  systems,  the  human 
resources  available  for  meeting  these  requirements  and  the  constraints  which  must  be  observed  in 
reaching  solutions”  (Shepherd,  1993).  In  HTA  the  analyst  is  prompted  to  determine  conditions 
when  various  subtasks  should  be  carried  out  in  order  to  meet  a  system’s  goals.  The  product  of 
the  HTA  is  a  hierarchy  of  operations  (the  different  things  that  people  must  do  within  a  system) 
and  plans  (statements  of  the  conditions  necessary  to  undertake  these  operations).  As  a  result  of 
the  hierarchical  nature  of  the  description,  the  analysis  can  be  developed  in  as  little,  or  as  much, 
detail  as  is  needed  to  deal  with  a  given  task.  The  HTA  can  be  presented  either  in  the  form  of  a 
table  or  in  graphical  form  (see  figure  1  for  an  example). 
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Figure  1.  Example  of  a  Portion  of  the  Hierarchical  Task  Analysis  (HTA). 


This  analysis  began  with  stating  the  overall  goal  to  be  achieved  :  Ejfictively  Specify  and 
Procure  Equipment.  The  goal  was  broken  down  (re  described)  into  operations,  and  an  associated 
plan  stating  when  the  operations  are  to  be  carried  out.  Examples  of  operations  are:  Analyze 
Mission  Areas,  Determine  Scope  of  Project,  Produce  Decision  Documents.  An  example  of  a 
plan  is:  Do  operation  1  then  operation  2  then  end.  When  satisfactied  that  the  re-description  is 


^The  major  major  conclusions  of  the  study  were  a  need  to  identify  relevant  stakeholders,  a  need  for  increased  user 
involvement,  a  need  to  improve  communications  channels  between  stakeholders,  a  need  for  improvements  in  trade¬ 
off  analyses,  and  a  need  for  improved  consideration  of  implementation  strategies. 
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adequate,  a  decision  is  made  regarding  whether  or  not  to  further  break  down  operations  into  sub¬ 
operations.  The  stopping  rules  used  were:  a)  that  there  was  no  apparent  problems  associated  with 
a  given  operation;  and  b)  that  it  was  not  necessary  to  break  down  the  operation  further  to  present 
a  solution  to  an  identified  problem.  If  further  re-description  was  necessary,  it  again  involved  the 
process  of  breaking  the  operation  down  into  subordinate  operations  and  an  associated  plan.  In 
the  example  in  Figure  1,  the  operation  Analyze  Mission  Areas  is  further  re-described  into  the 
following  sub-operations:  Identify  Deficiencies  in  Capabilities  and  Identify  More  Effective  Means 
of  Performing  Assigned  Tasks. 


THE  NEED  TO  BRING  HFE  AND  USERS  INTO  THE  DESIGN  PROCESS  EARLIER 


One  clear  conclusion  from  the  HTA  was  that  the  personal  equipment  development 
process  involves  several  activities  which  occur  prior  to  the  initial  activities  specified  by  MIL- 
STD-46855  (see  Figure  2).  This  is  apparent  if  the  overall  DND  acquisition  process  is  examined 
(Figure  3). 
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Figure  2.  Human  Factors  Activities  Specified  by  MIL-H-46855B 


The  acquisition  or  development  process  occurs  in  direct  response  to  a  requirement  for  a 
specified  capability  in  the  CF.  Activities  associated  with  the  acquisition  process  commence  with 
a  Problem  Analysis  and  conclude  with  the  acceptance  of  the  new  or  modified  system.  The  first 
phase  of  Project  Initiation  concludes  with  the  preparation  of  a  Preliminary  Statement  of 
Requirements  (SOR).  The  SOR  is  a  document  which  describes  an  equipment  item  in  terms  of 
the  operational  needs,  and  which  states  the  minimum  essential  performance  requirements  that  the 
DND  has  determined  necessary.  Since  the  SOR  is  the  initial  step  in  a  long  process,  it  is  critical 
that  this  document  reflect  the  users’  requirements  and  that  the  information  contained  within  the 
document  is  presented  to  designers  in  a  manner  that  is  clear,  complete,  and  can  be  validated 
(Shepherd  and  Ormerod,  1992). 


DPMS  Phases 


Figure  3;  Defence  Programme  Management  System  Phases  and  Associated  Management  Tasks 


Recent  HFE  literature  suggests  that  requirements  for  new  systems  should  be  developed 
with  users  and  stakeholders  in  an  iterative  manner  (see  Beevis,  Essens  &  Mack,  1993).  This 
implies  a  further  broadening  of  the  scope  of  requirements  definition  activities.  Yet  there  are  few 
guidelines  available  to  help  with  this  activity.  There  have  been  many  attempts  to  develop  tools 
to  improve  the  application  of  HFE  in  the  concept  development  and  design  phases  of  system 
development  (Karkowski,  Genaidy  and  Asfour,  1990,  for  example).  In  contrast,  few  tools  have 
been  identified  for  addressing  user  requirements  at  the  outset  of  a  development  project  (Eason, 
1988). 


USERS  AND  USER  REPRESENTATION  IN  THE  DESIGN  PROCESS 


As  outlined  above,  the  end  users  are  key  stakeholders  in  the  development  and  acquisition 
process.  Currently  there  are  two  major  sources  of  user  input  into  that  process  from  the  ‘field’: 
feedback  concerning  the  limitations  of  current  systems  and  equipment,  and  information  from 
persons  familiar  with  the  users’  needs. 

Feedback  From  Users 


There  are  two  opportunities  for  equipment  users  in  the  field  to  relay  information  back  to 
designers  regarding  equipment  performance.  The  first  is  accomplished  by  filling  out  an 
Unsatisfactory  Condition  Report  (UCR)  and  the  second  is  indirectly  through  a  safety  report  filed 
after  an  accident. 

UCRs  are  available  to  all  service  people  to  complete  when  they  feel  a  piece  of  equipment 
does  not  allow  them  to  effectively  perform  their  duties.  The  paperwork  burden  associated  with 
filing  a  UCR  however,  can  be  daunting.  The  forms,  which  have  to  be  duplicated  locally,  are  time 
consuming  to  fill  out.  Further,  approval  and  agreement  must  be  granted  from  superiors  as  the 
paperwork  moves  towards  its  final  destination.  To  complicate  matters  further,  the  UCR  is 
transferred  from  the  operational  chain  of  command  to  the  maintenance  chain  of  command  on  its 
travels.  The  multiple  levels  of  review  and  approval  result  in  a  time  lag  and  also  in  a  feeling  of 
helplessness  on  the  part  of  users.  When  combined  with  the  attitude  that  “if  it  has  been  this  way 
for  the  last  twenty  years  and  it  was  good  enough  for  all  those  soldiers,  it  is  good  enough  for  you”, 
there  are  many  fewer  UCRs  submitted  than  might  be  expected.  The  lack  of  UCRs  on  any 
particular  item  does  not  necessarily  reflect  acceptance  in  the  field.  It  has  been  known  to  occur 
that  an  item  of  equipment  is  put  into  service  but  is  not  routinely  used  in  the  field.  As  a  result, 
there  is  little  feedback,  good  or  bad,  about  its  performance.  The  lack  of  feedback  leads  to 
assumptions  by  headquarters  that  the  equipment  development  and  acquisition  has  been 
successful. 

Users  may  have  the  opportunity  of  participating  in  the  development  and  acquisition 
process  if  they  are  asked  to  become  involved  in  the  test  and  evaluation  of  new  equipment  items. 
Often  however,  the  test  and  evaluation  is  conducted  by  a  dedicated  test  and  evaluation  unit.  This 
means  that  the  majority  of  users  are  excluded  from  the  process. 

User  Representatives  And  Their  Impact 


The  Directorate  of  Land  Requirements  (DLR)  represents  the  interests  of  field  users  of 
new  systems  and  equipment.  DLR  personnel  are  former  equipment  users  who  are  assigned  to  a 
staff  position  for  a  number  of  years.  They  are  considered  to  be  “operators”  as  they  were 
previously  equipment  users,  and  are  considered  to  be  representative  of  current  users.  Their 
responsibilities  center  around  the  determination  and  elaboration  of  the  equipment  requirements 
of  the  Land  Forces.  In  this  role  they  are  called  Project  Directors  (PD).  The  primary  product  of 
their  involvement  in  the  acquisition/development  cycle  is  the  Statement  of  Requirements  (SOR). 
The  PD  tends  to  have  little  or  no  formal  training  in  HFE  or  in  requirements  specification  writing. 
They  are  expected  to  learn  on  the  job  through  practice  and  experience. 

This  lack  of  training  is  reflected  in  the  attitude  of  PDs  to  user  requirements.  In  the 
questionnaire  survey,  when  asked  who  they  collaborated  with  in  developing  the  requirements  for 
new  systems  and  equipment,  only  HFE  specialists  mentioned  collaborating  with  field  users.  In 
follow-up  interviews,  respondents  confirmed  that  they  felt  that  the  user  was  adequately 
represented  through  the  inclusion  of  the  Requirements  Officer. 


While  in  theory  the  use  of  full-time  user  representatives  affords  a  means  for  users  to  play 
a  detailed  role  in  equipment  development,  there  are  several  disadvantages  to  this  approach. 

These  are  discussed  below. 

Hostage  Effect  -  The  main  disadvantage  with  the  current  form  of  user  representation  is 
that  in  taking  an  individual  from  the  field,  m^ng  him/her  a  staff  officer,  and  then  thrusting 
him/her  into  an  administrative  network,  the  individual  soon  becomes  indoctrinated  and  socialized 
into  the  culture  of  the  staff  officer  and  ceases  to  be  a  true  user.  This  individual  may  now  become 
an  excellent  project  administrator,  but  a  poor  user  representative.  Hedberg  (1975)  terms  this  the 
“hostage  effect”,  where  a  user  joins  a  design  team  composed  of  technical  specialists  on  a  full 
time  basis,  and  before  long,  the  individual  has  acquired  not  only  the  skills,  but  also  the 
ambitions,  values,  and  attributes  of  the  other  team  members.  Ideally,  the  user  representative 
should  be  able  to  challenge  the  views  of  the  rest  of  the  team  members  in  presenting  the  user’s 
viewpoint.  The  user  representative  suffering  from  the  hostage  effect  will  not  be  able  to.  As  a 
result  there  may  be  a  negative  or  hostile  reaction  to  the  equipment  when  fielded  because  the  field 
users  have  not  been  able  to  contribute  their  knowledge  or  ensure  that  issues  that  concern  them 
have  been  adequately  addressed. 

Use  of  a  user  representative  can  result  in  the  majority  of  users  being  excluded  from  the 
design  process.  Eason  (1988)  argues  that  if  the  hostage  effect  occurs,  “the  remainder  of  users 
tend  to  be  consulted  less  than  they  might  have  been  had  there  been  no  user  representative”.  In  a 
worse  case  scenario,  the  team  may  believe  that  they  have  all  the  ‘user’  knowledge  they  require  in 
their  immediate  team.  They  may  confuse  the  enthusiasm  of  the  user  representative  for  actual 
feedback  from  users  in  the  field  and  not  consult  widely  with  the  user  community.  This  could 
lead  to  serious  disappointment  when  late  in  a  project  it  is  realized  that  the  equipment  users  in  the 
field  have  a  very  different  idea  of  what  they  want. 

Limited  representation  of  rank  -  User  representatives  tend  to  be  senior  officers  (rank  of 
Major).  This  is  appropriate  for  staff  responsibilities  and  for  discussions  of  strategic  nature  where 
an  appreciation  of  the  implications  of  a  potential  system  is  needed.  A  senior  rank  may  also  be 
advantageous  for  fostering  debate  amongst  colleagues  and  mustering  the  resources  required  to 
pursue  the  study  of  the  implications  of  a  proposed  system.  Using  a  senior  staff  member  as  part 
of  a  design  team  however,  may  not  be  as  useful.  Staff  officers  are  removed  from  the  day-to-day 
operations  in  the  field  and  may  not  be  aware  of  the  significance  of  many  design  decisions.  If  a 
user  representative  is  to  be  used,  the  person  should  be  one  with  considerable  experience  in 
“field”  operations  and  one  who  can  point  out  limitations  of  design  options. 

Limited  representation  of  user  areas  -  User  representatives  should  be  chosen  from  the 
various  user  areas  to  be  affected  by  the  new  equipment.  Clearly,  this  points  back  to  the  need  for 
a  clear  and  complete  Stakeholder  Analysis. 

Lack  of  continuity  of  staffing  -  User  representatives  are  rotated.  The  CF  attempts  to 
provide  its  staff  with  a  range  of  work  experience.  One  of  the  positions  that  an  officer  can  occupy 
is  that  of  user  representative,  or  requirements  officer.  Rotation  can  be  positive  in  that  it  can 
counter  the  “hostage”  effect.  However,  the  negative  aspects  far  outweigh  the  positive.  It  takes  a 
great  deal  of  time  for  an  individual  to  become  a  competent  user  representative,  familiar  with  the 
bureaucracy  of  the  development  and  acquisition  process.  Rotation  results  in  removal  of  these 
resources  just  as  they  are  about  to  pay  dividends.  Further,  both  formal  and  informal  channels  of 
communications  can  be  built  up  by  these  individuals,  for  instance  ties  whereby  information  about 
user  needs  is  transmitted,  and  rotation  often  results  in  the  breakdown  of  these  channels.  As  a 
result,  it  appears  best  to  go  for  continuity  on  position  and  role  if  possible. 

Biased  viewpoint  of  user  representatives  -  User  representatives  are  required  to  provide 
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information  on  the  users  to  other  members  of  the  design  team.  This  can  reinforce  the  perception 
that  they  truly  represent  the  users.  Cases  have  even  occurred  where  the  requirements  personnel 
consider  themselves  to  represent  field  users  to  the  point  of  their  being  physically  the  same,  so 
that  mockups  and  prototypes  are  judged  on  the  criteria  that  “I  have  normal  hands  (or  seated  eye 
height,  or  reach  etc.)  and  I  can  use  the  equipment,  so  it  is  acceptable.” 


POSSIBLE  SOLUTIONS 


The  various  problems  associated  with  the  current  user  representative  strategy  point  to  the 
need  for  a  more  user-centered  approach  to  the  development  and  acquisition  process. 
Unfortunately,  given  the  other  organizational  priorities  of  the  Department  at  the  present,  it  is  not 
likely  that  a  shift  to  a  user-centered  approach  will  take  place  in  the  short  term.  It  is  necessary 
therefore  to  consider  ways  which  may  increase  user  involvement  and  improve  the  representation 
of  users  in  the  development  and  acquisition  process.  Two  approaches  are  being  examined  at 
DCIEM  to  accomplish  this  goal.  The  first  focuses  on  allowing  part-time  user  representatives  to 
develop  a  profile  of  themselves,  the  second  centers  around  a  more  rigid  management  of  HFE 
procedures. 


Increase  User  Specification  Through  Increased  User  Involvement  And  Representation 


It  is  not  possible  for  every  stakeholder  in  a  development  and  acquisition  project  to  be 
involved  in  every  decision.  Strategic  decisions  are  best  left  to  staff  officers,  while  decisions 
regarding  user  needs  are  best  left  to  the  users  themselves.  At  present,  there  is  no  avenue  for  field 
users  to  participate  in  the  process.  There  is  a  need  for  a  means  of  managing  the  project,  handling 
all  the  requisite  interaction  between  stakeholders,  and  yet  not  allowing  the  process  to  degenerate 
into  the  chaos  represented  by  statements  such  as  “you  ask  ten  users  for  their  opinion  and  you  will 
get  eleven  replies.” 

To  allow  the  views  and  requirements  of  users  to  permeate  acquisition  projects,  use  could 
be  made  of  part-time  user  representatives  taken  directly  from  the  “field”  who  continue  to  operate 
within  that  context.  The  part-time  user  representative  could  in  effect  become  the  advocates  of 
user  requirements  and  could  be  involved  directly  in  the  evaluation  of  alternative  design  solutions 
against  user  requirements.  The  intent  of  this  approach  is  to  allow  users  to  become  actively 
involved  in  specifying  themselves  and  their  characteristics.  In  essence,  this  empowers  users, 
through  the  part-time  “field-based”  user  representatives,  to  “sign-off’  at  various  stages  in  the 
design  process. 

The  use  of  part-time  user  representatives  in  this  manner  necessitates  the  establishment  of 
a  forum  for  them  to  present  their  feedback  to  the  project.  Such  a  forum  could  take  the  form  of  a 
Project  Review  Meeting,  where  a  list  of  CF  acquisition  projects  could  be  considered.  This  would 
allow  the  user  representatives  to  be  involved  in  more  than  one  project  at  a  time,  and  would  afford 
them  the  awareness  of  the  problems  associated  with  the  interface  between  projects  (i.e.. 
compatibility,  usability  etc.).  A  user  representative  empowered  to  consider  all  new  equipment 
items  and  their  interaction  in  unison  would  be  more  effective  in  such  a  role  than  a 
compartmentalized  senior  manager. 

One  means  of  mediating  this  process,  is  through  the  use  of  a  series  of  matrices  that  build 
upon  each  other.  An  example  of  such  a  matrix  which  incorporates  design  team  constraints,  user 
roles,  user  characteristics  and  equipment  functions  is  presented  in  Figure  4.  Interacting  factors 
are  identified  with  a  check  mark  and  examined  in  further  detail.  By  examining  these  factors  it  is 
possible  to  ensure  that  there  is  a  match  between  the  expected  equipment  functionality  and  the 


user  tasks  and  characteristics  as  defined  by  the  development  and  acquisition  team  in  conjunction 
with  users. 
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Figure  4.  Users/Tasks/Equipment  Functionality  Matrix. 


In  filling  out  the  matrices,  there  are  a  number  of  user  characteristics  which  can  be  defined 
in  the  form  of  a  person  specification.  The  person  specification  contributes  much  of  the 
background  information  needed  to  clearly  specify  user  constraints  to  the  design  team.  Examples 
of  factors  which  can  be  detailed  in  this  manner  are  user  anthropometries,  user  strength  and 
stamina,  and  user  gender. 


Increase  User  Specification  Through  More  Structured  Approach  to  Documentation 


A  review  of  ten  major  projects  of  the  Canadian  Department  of  Defence  (DND)  reached 
several  conclusions  relevant  to  the  application  of  HFE  in  the  systems  design  and  development 
process  (Beevis,  1987).  The  review  noted  that  a  coordinating  committee  with  representatives 
from  operators,  engineering  specialties,  and  human  factors  engineering  had  been  very  effective  in 
articulating  and  managing  the  customer’s  approach  to  design  requirements  involving  human 
factors  issues.  The  review  also  concluded  that  the  application  of  HFE  appeared  to  be  facilitated 
by  the  preparation  of  a  Human  Engineering  Project  Plan  (HEPP).  Those  projects  that  had  used  a 
Human  Engineering  Project  Plan  had  involved  a  wider  scope  of  HFE  activities  than  those  that 
had  not  used  such  a  plan.  Human  Engineering  Project  Plans  are  prepared  by  the  contractors  at 
the  outset  of  a  project  to  define  the  scope  of  the  human  factors  engineering  effort.  Typically,  the 
HEPP  is  specified  by  US  DoD  DI-HFAC-80740  and  based  on  US  MIL-STD-46855. 

The  HEPP  forces  the  systems  developers  and  the  procuring  agency  to  agree  on  what  will 
be  done  to  design  for  the  users  of  the  system  or  equipment.  One  possible  reason  for  the 
effectiveness  of  the  HEPP  is  that  it  compensates  for  the  lack  of  HFE  activities  in  the  work 
breakdown  structures  (WBS)  typically  used  for  military  systems  (MIL-STD-881B:  Work 
Breakdown  Structure  for  Defense  Materiel  Items,  25  March  1993).  Examination  of  that  standard 
shows  that  no  single  item  can  be  associated  with  human  factors  engineering  in  any  of  the 
exemplar  military  systems  which  are  addressed  by  the  standard.  Thus  no  one  item  in  the  WBS 
can  be  associated  with  human  factors  engineering.  Instead,  responsibilities  for  HFE  are 
distributed  across  many  items  of  the  WBS. 

A  comprehensive  HEPP  will  address  HFE  activities  starting  with  the  drafting  of  a  system 
specification  and  ending  with  test  and  evaluation.  The  DND  document  governing  specification 
preparation  (D-01-300-100/SG-000, 1  August  1979)  permits  the  inclusion  of  ‘Technical  and 
mission  requirements  for  the  complete  system;’  ‘Interfaces  between  functional  areas  and  other 
systems;’  and  ‘Performance  characteristics.’  Each  of  these  topics  could  be  used  to  address  HFE 
or  user  requirements  such  as  the  need  for  equipment  to  be  operable  by  a  specified  range  of  CF 
personnel,  with  specified  training  and  experience,  in  specified  conditions.  The  ideal  would  be  to 
follow  the  US  Army’s  Manpower  Integration  (MANPRINT)  Program  in  providing  the  basis  for 
answering  the  question: 

“Can  this  soldier ,  with  this  training,  perform  these  tasks,  to  these  standards ,  under  these 

conditions?. 

US  MIL-STD  490A  Specification  Practices  provides  a  more  thorough  basis  for 
specifying  user  requirements.  Para  4.3. 3.7  of  that  standard  states  that  “Human  engineering 
requirements  ...  should  be  specified  herein  ...  This  paragraph  should  also  specify  any  special  or 
unique  requirements,  e.g.,  constraints  on  allocation  of  functions  to  personnel,  and 
communications  and  personnel/equipment  interactions.  Included,  should  be  those  specified 
areas,  stations,  or  equipment  that  require  concentrated  human  engineering  attention  due  to  the 
sensitivity  of  the  operation  or  criticality  of  the  task,  i.e.,  those  areas  where  the  effects  of  human 
error  would  be  particularly  serious.”  This  provides  an  opportunity  to  describe  the  users  and  their 
operations  as  they  affect  the  performance  of  the  system.  Similarly,  paragraph  4.3.6.  requires  that 
“requirements  imposed  by  or  limited  by  personnel  or  training  considerations  shall  be  specified 
....”  thus  providing  an  opportunity  to  specify  the  level  of  training  which  the  operators  will  have 
prior  to  being  training  on  the  system. 

The  user  requirements  included  in  the  specification  must  be  reviewed  as  the  design 
progresses  or  as  part  of  the  proposals  for  an  off-the-shelf  acquisition.  US  MIL-STD-1521  B 
(USAF)  Technical  reviews  and  audits  for  systems,  equipments,  and  computer  software  includes 
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provision  for  reviewing  the  following: 

a.  as  part  of  the  System  Requirements  Review 

(1)  human  factors  analysis;  and 

(2)  manpower  requirements/personnel  analysis;  and 

b.  as  part  of  the  System  Design  Review 

(1)  human  factors;  and 

(2)  training  and  training  support ;  and 

c.  as  part  of  the  Preliminary  Design  Review  and  the  Critical  Design  Review 

(1)  mock-ups,  models,  breadboards,  or  prototype  hardware;  and 

(2)  human  engineering  and  biomedical  considerations. 

For  test  and  evaluation  purposes,  MIL-H-46855B  requires  that  “Human  engineering  test 
planning  shall  be  directed  toward  verifying  that  the  system  can  be  operated,  maintained, 
supported  and  controlled  by  user  personnel  in  its  intended  operational  environment.  Human 
engineering  test  planning  should  also  consider  data  needed  or  to  be  provided  by  operational  test 
and  evaluation.  Test  planning  shall  include  methods  of  testing  (e.g.,  use  of  checklists,  data 
sheets,  test  participant  descriptors,  questionnaires,  operating  procedures,  and  test  procedures), 
schedules,  quantitative  measures,  test  criteria  and  reporting  processes.”  Compliance  with  this 
requirement  would  necessitate  user  input  to  describe  the  test  participants,  and  agree  to  the  test 
criteria. 

Overall,  then,  existing  documentation  provides  the  framework  for  a  much  improved 
approach  to  specifying  user  requirements  in  CF  acquisition  projects.  One  of  the  problems  with 
much  of  the  development  and  acquisition  process  as  a  whole,  is  that  it  emphasizes  technical  areas 
and  pays  little  or  no  attention  to  the  context  in  which  the  equipment  will  be  used.  As  an 
example,  when  an  SOR  is  passed  to  an  advisory  agency,  say  DCIEM,  it  is  usually  circulated 
amongst  subject  matter  experts  to  ensure  that  all  relevant  HFE  issues  have  been  considered.  This 
is  often  done  against  severe  time  constraints  due  the  last  minute  need  to  include  human  factors  in 
the  process.  Since  there  is  little  context  provided,  inputs  tend  to  be  generic  catch-all  phrases  (e.g. 
“the  equipment  item  must  be  compatible  with  all  CF  vehicles.”) 

The  problem  inherent  in  this  process  can  be  further  illustrated  in  the  example  of  the 
operational  need  that  a  105  mm  Howitzer  Field  Gun  be  “accurate”.  Accuracy  from  a  human 
factors  engineering  perspective  is  quite  different  from  that  of  the  engineering  discipline.  The 
strict  engineering  interpretation  of  accuracy  is  based  on  quasi-laboratory  test  with  the  gun 
thoroughly  supported  or  “bedded  in”,  carefully  calibrated,  and  operators  taking  plenty  of  time  to 
aim  (Humaniyi'tgmj',  1991).  This  particular  weapon  system  may  prove  very  accurate  in  the  lab 
test  as  it  is  well  bedded  down  and  carefully  fired.  The  same  equipment  may  be  very  inaccurate 
when  fired  by  soldiers  who  must  operate  the  weapon  in  a  much  wider  operational  context.  The 
bottom  line  from  the  human  factors  engineering  perspective  is  the  level  of  accuracy  which  can  be 
achieved  in  the  field  under  normal  operational  circumstances. 

Clearly,  all  the  stakeholders  in  the  development  and  acquisition  process  need  to  know  the 
context  in  which  the  equipment  will  be  used.  This  is  particularly  true  of  personal  equipment. 

Few  designers  of  advanced  systems  have  the  opportunity  to  observe  how  they  are  used  in 
practice.  One  development  being  undertaken  for  the  Canadian  Forces  is  aimed  at  providing  all 
participants  in  the  development  and  acquisition  process  with  the  context  of  the  roles  and  tasks 
that  operators  perform,  as  an  aid  to  understanding  how  their  equipment  will  be  used. 
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THE  SOLDIERS  DAY 


The  Soldier’s  Day  multimedia  database  is  being  developed  (through  a  contract  with 
HumanSyi'tem^  Incorporated  of  Guelph,  Ontario)  as  part  of  an  initiative  to  provide  baseline  data 
to  requirements  officers,  engineering  agencies,  research  establishments  and  contractors.  Users 
within  these  groups  were  surveyed  to  determine  their  information  needs.  These  needs  were 
situated  within  the  four  major  categories:  clothing  and  equipment,  organization  and  the  soldier, 
and  roles/tasks  and  activities,  and  Human  Factors  related  information  (at  the  moment,  human 
factors  information  is  restricted  to  references).  The  database  has  been  structured  around  these 
four  data  streams  and  this  is  highlighted  in  Figure  4,  the  opening  screen  from  the  database. 


Figure  4.  Soldier's  Day  Database  Opening  Screen  showing  the  structure  of  the  database. 


The  information  available  in  the  Soldiers  Day  database  supplements  the  information 
required  in  order  to  specify  users  and  their  roles.  By  feeding  the  information  from  the  Soldier’s 
Day  into  the  matrices  discussed  above,  a  common  context-rich  frame  of  reference  should  be 
established  for  both  users  and  development  and  acquisition  participants.  Each  data  stream  and  its 
associated  data  items  and  use  is  discussed  below  through  the  use  of  screen  shots. 
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Clothing  and  equipment 


Figure  5  is  a  screen  shot  depicting  the  main  database  interface,  in  this  case  for  the 
clothing  and  equipment  data  stream.  In  diis  example,  the  user  is  accessing  information  on  the 
1982  pattern  webbing.  The  upper  left  hand  window  is  used  to  display  audio  visual  information 
in  the  form  of  photographs,  videos,  and  schematics/graphics.  The  right  hand  window  is  used  to 
display  textual  information.  This  information  may  take  the  form  of  general  equipment  item 
descriptions,  more  detailed  technical  descriptions,  training  material  etc.  Associated  equipment 
items  (component  parts )  and  the  items  which  interact  with  the  selected  equipment  items 
(compatibility)  can  be  accessed  from  the  ‘Item  and  Associated  Equipment’  dialogue  box.  A.  link 
to  associated  items  in  the  organizational  or  activity  data  streams  can  also  be  made  by  selecting 
the  appropriate  radio  button  on  the  left  hand  side  of  the  screen.  This  encourages  the  user  to 
explore  links  with  the  other  data  streams.  For  example,  by  selecting  Associated  Soldiers,  the 
user  can  transition  to  the  organization/soldier  data  stream  and  can  examine  who  wears  webbing. 
By  transitioning  to  the  I  data  stream,  the  user  can  explore  under  what  conditions  the  equipment 
will  be  employed. 
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Figure  5.  The  Soldier’s  Day  database  interface  for  the  Clothing  and  Equipment  data  stream. 


Organizational  Structure 


The  organizational  data  stream  contains  general  information  on  the  organization  of 


soldiers.  By  following  a  hierarchical  schematic,  one  can  examine  various  levels  of  organization 
and  retrieve  general  knowledge  about  these.  The  Soldier’s  Day  database  focuses  in  detail  on  the 
rifleman,  the  lowest  level  in  the  hierarchy.  In  the  example  screen  shot,  (Figure  6)  the  user  is 
accessing  information  about  rifleman  demographics,  in  this  case,  weapons  use.  The  user  also  has 
the  capability  to  move  upwards  to  examine  higher  levels  of  organization  or  to  examine  associated 
equipment,  activities  or  references. 
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Figure  6.  Screen  shot  of  the  Organization  data  stream  focusing  in  on  Rifleman  weapons  use. 


Operations 


The  operations  data  stream  contains  information  on  soldier  Roles,  Tasks  and  Activities. 
The  user  is  encouraged  to  explore  a  hierarchical  breakdown  of  soldier  Tasks  and  Activities  in 
order  to  better  understand  how  equipment  will  be  used.  Figure  7  is  a  representative  screen  shot 
for  the  activities  data  stream.  Here  the  user  is  accessing  information  on  C7  Rifle  Firing  in  the 
prone  position.  Photographs  and  videos  are  provided  to  allow  the  user  to  explore  how  the  C7 
rifle  is  employed  and  under  what  conditions.  Related  activities  or  higher  order  tasks  and  roles 
can  also  be  examined.  Linkages  can  be  made  between  this  and  the  other  data  streams. 
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Figure  7.  Screen  shot  of  the  Roles/Tasks/Activites  data  stream  focussing  on  C7  Rifle  Firing. 


CONCLUSIONS 

There  is  a  need  to  move  towards  a  more  user-centered  approach  to  the  design  of  personal 
equipment.  There  is  room  for  improvement  of  the  full-time  user  representative  strategy  currently 
being  used.  Existing  regulatory  documents  provide  the  framework  for  a  much-improved 
application  of  user  requirements  in  the  acquisition  process.  User  representation  and  involvement 
can  be  improved  by  the  introduction  of  part-time  user  representatives  into  the  process.  Matrices 
can  be  used  to  identify  target  users,  assist  in  the  preliminary  specification  of  an  equipment  item’s 
functionality,  and  ensure  that  user  tasks,  user  characteristics  and  equipment  functionality  are 
matched  to  one  another.  It  is  hoped  that  in  the  interim,  while  a  more  user-centered  approach  is 
being  developed,  the  Soldier’s  Day  database  will  foster  an  improved  understanding  of  user  roles 
and  tasks.  A  heightened  focus  on  the  specification  of  users  and  their  roles  will  enhance  the 
systems  development  process  and  so  result  in  better  products  produced  for  users  in  the  field. 
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